Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-moore-smtp-drpt-00.txt < prev next >

Wrap

Text File | 1993-09-17 | 21.1 KB | 548 lines

Network Working Group Keith Moore Internet Draft University of Tennessee 16 September 1993 SMTP Service Extension for Delivery Reports draft-moore-smtp-drpt-00.txt 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. (The file 1id-abstracts.txt, available via anonymous ftp from nic.ddn.mil, describes the current status of each Internet Draft.) It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". 2. Abstract This memo defines an extension to the SMTP service whereby the an SMTP client may specify to an SMTP server the conditions under which a delivery report should be generated. 3. Introduction The SMTP protocol [1] requires that an SMTP server provide notification of delivery failure, if it determines that a message cannot be delivered to one or more recipients. Traditionally, such notification consists of an ordinary Internet mail message (format defined by [2]), sent to the envelope sender address (the argument of the SMTP MAIL command), containing an explanation of the error and at least the headers the failed message. Experiences with large mail distribution lists [3] indicates that such messages are often insufficient to diagnose problems, or even to determine at which host or for which recipients a problem occurred. In addition, the lack of a standardized format for delivery notifications in Internet mail makes it difficult to exchange such notifications with other message handling systems. This memo uses the mechanism defined in [4] to define an extension to the SMTP service, by which an SMTP client may request that an SMTP server issue or not issue a delivery status notification (DSN) under certain conditions. The format of a DSN is defined in [5]. K. Moore Expires 16 March 1994 [Page 1] Delivery Reports 16 September 1993 4. Framework for the Delivery Report Extension The following service extension is therefore defined: (1) The name of the SMTP service extension is "Delivery Report"; (2) the EHLO keyword value associated with this extension is "DRPT", the meaning of which is defined in section 5 of this memo; (3) no parameters are allowed with this EHLO keyword value; (4) three optional parameters are added to the RCPT command, and one optional parameter is added to the MAIL command: An optional parameter for the RCPT command, using the esmtp-keyword "DRPT", (to request a delivery-report), is defined in section 6.1, An optional parameter for the RCPT command, using the esmtp-keyword "NORET", (to specify that delivery reports not return the contents of a message), is defined in section 6.2, An optional parameter for the RCPT command, using the keyword "TAG", (used to communicate additional information for use by internetwork mail gateways), is defined in section 6.3, and An optional parameter for the MAIL command, using the keyword "MSGID", (used to propagate a unique identifier to be returned in a delivery report), is defined in section 6.4; (5) no additional SMTP verbs are defined by this extension. The remainder of this memo specifies how support for the extension affects the behavior of a client and server SMTP. 5. The Delivery Report service extension An SMTP client wishing to request a delivery report for a message may issue the EHLO command to start an SMTP session, to determine if the server supports any of several service extensions. If the server responds with code 250 to the EHLO command, and the response includes the EHLO keyword DRPT, then the Delivery Report extension is supported. When any SMTP server returns a positive (2xx) reply code in response to a RCPT command, agrees to accept responsibility for either delivering the message to the named recipient, or sending a notification to the sender of the message indicating that delivery has failed. By returning a DRPT keyword in response to an EHLO command, a server also agrees to generate a Delivery Status Notification (DSN) according to the parameters of each RCPT command, when it returns a positive response to the RCPT command. (The client SMTP is responsible for generating the K. Moore Expires 16 March 1994 [Page 2] Delivery Reports 16 September 1993 necessary delivery reports if the server SMTP returns a failure reply code.) Such DSNs must be in the format defined in [5]. The additional parameters allow the sender (via the client SMTP) to specify that a delivery report should be issued: (a) upon successful delivery or failure to deliver a message, or (b) only on failure to deliver a message, or (c) not at all. In addition, the sender may specify that the contents of a message are not to be returned in a delivery report. 6. Additional parameters for RCPT and MAIL commands The extended RCPT and MAIL commands are issued by a client with it wishes to request a delivery report from the server, under certain conditions, for a particular recipient. The extended RCPT and MAIL commands are identical to the RCPT and FROM commands defined in [1], except that one or more of the following parameters appear after the sender or recipient address, respectively. The general syntax for extended SMTP commands is defined in [4]. 6.1 The DRPT parameter of the ESMTP RCPT command The esmtp-keyword "DRPT" may be appear in the RCPT command to modify the default behavior of the MTA when generating delivery notifications for that recipient. Acceptable esmtp-values for the DRPT parameter are the following: ALWAYS always generate a delivery report on delivery FAILURE generate a delivery report on delivery failure only NEVER do not generate a delivery report If no DRPT parameter appears, the server should generate a delivery report only upon failure to deliver a message. This is the behavior specified by [1]. Ideally, servers should use the delivery report format defined in [5] to report delivery failures, even if they do not implement this SMTP extension. A DRPT esmtp-keyword with an esmtp-value of ALWAYS indicates that the server should accept responsibility for generating a DSN (in the correct format) upon any of the following conditions: (a) successful delivery to the indicated recipient's mailbox, (b) relaying or gatewaying of the message into a environment that cannot or will not accept responsibility for generating well-formatted DSNs, (c) forwarding of the message to a mailbox other than that specified by the sender, or (d) failure to deliver a message. K. Moore Expires 16 March 1994 [Page 3] Delivery Reports 16 September 1993 A DRPT esmtp-keyword with an esmtp-value of FAILURE indicates that the server should accept responsibility for generating a DSN when (a) relaying or gatewaying of the message into an environment that cannot or will not accept responsibility for generating well-formatted DSNs, or (b) forwarding of the message to a mailbox other than that specified by the sender, or (c) failure to deliver the message. A DRPT esmtp-keyword with an esmtp-value of NEVER indicates that the server should not generate a DSN under any conditions, and should accept responsibility for ensuring that no DSN is generated for this recipient. (If the message is further relayed via a SMTP server that does not support this extension, this may be accomplished by using an empty sender address in the MAIL command. This may require a separate SMTP session if not all recipients have DRPT=NEVER.) 6.2 The NORET parameter of the ESMTP RCPT command The presense of the NORET esmtp-keyword on the extended RCPT command indicates that the message should not be included in any delivery notification issued for this recipient. A missing NORET parameter indicates that a message should be returned in a delivery notification for this recipient. 6.3 The TAG parameter to the ESMTP RCPT command A TAG esmtp-keyword is used to convey additional per-recipient information for messages which originated in an non-SMTP environment, and for which a delivery report was requested by the sender. The definition of the esmtp-value is not defined by this memo; the definition to be provided by the specifications for gatewaying delivery reports to and from non-SMTP environments. 6.4 The MGSID parameter to the ESMTP MAIL command The optional MSGID esmtp-keyword may appear in the MAIL SMTP command. The esmtp-value associated with this string is formatted according to the rules for "msg-id" in [2]. Note that this value is not necessarily the same as in the Message-ID header field of the message. 6.5 Server responses to these commands The presence of any of the DRPT, NORET, or TAG esmtp-keywords in a RCPT command, or the MSGID esmtp-keyword in a MAIL command, does not affect the server's response to that command (unless there is a syntax error in the command itself). By issuing the DRPT keyword in response to the EHLO command, the server has indicated its willingness to accept these keywords and to process them according to the rules below. A K. Moore Expires 16 March 1994 [Page 4] Delivery Reports 16 September 1993 server MAY NOT refuse the responsibility to issue delivery reports on a per-recipient basis. 7. Format of delivery notifications The format of delivery status notifications is defined in [5]. Delivery status notifications are to be returned to the sender of the original message according as outlined below. 7.1 SMTP Envelope to be used with delivery status notifications The sender address (in the SMTP MAIL command) must be an empty string. The recipient address (in the RCPT command) is copied from the MAIL command of the message for which a delivery notification is being issued. The envelope of a delivery notification may not use the DRPT option. 7.2 Message/delivery-report Content-Type Header Parameters The parameters of the message/delivery-report content type are derived as follows: The "id" parameter of the delivery-report contains the envelope message-id as provided with the MSGID esmtp-keyword of the MAIL command of the message for which a report is being generated. Unless the sender requested that the message not be returned in a delivery report, a unique content-id is generated by the reporting MTA, and the "returned-content" parameter of the message/delivery-report content-type header is used to indicate the content-id of that body part. *** NOTE IN DRAFT: It might be that delivery reports should include the *headers* of a failed message, even if the sender requested that the message not be returned. *** If the text of any of the "text" body fields requires a character set other than ASCII, the "charset" parameter should be used to indicate that character set. Only one "alternate" character set may be used per delivery notification. (This feature will not be used if the "text" is copied from SMTP responses, since SMTP responses must be entirely in ASCII.) 7.3 Message/delivery-report body field parameters The body of the message/delivery-report body part contains a STIF [6] record for each recipient. The fields of this per-recipient record are K. Moore Expires 16 March 1994 [Page 5] Delivery Reports 16 September 1993 derived as described below. These instructions apply to the generation of delivery reports by an ESMTP client that supports this specification, in response to SMTP or ESMTP transactions with a server. If an ESMTP client uses some other protocol to deliver or relay a message, some of the per-recipient fields are not required. Refer to [5] for the syntax of each field. orig-rcpt contains the recipient address from the RCPT command. (Since this specification guarantees that the recipient address is the same as specified by the sender, the "rcpt" field should not be used.) mta contains the Internet domain name of the SMTP that provided the information from which this report is derived. This will normally be the same as provided in the server's initial greeting and the first line of the response to the EHLO command. date contains the date at which the last delivery attempt occurred. action describes the action taken by the SMTP client generating the report, as defined in section 8. status If available, the reply-code returned by the "remote" SMTP server that informed "this" SMTP client (the one issuing the report) of the condition that caused the client to generate the report for this recipient. (This field is not required if the MTA generating the report used some protocol other than SMTP to deliver or relay the message.) text Either the text supplied by the "remote" SMTP along with the reply-code in "status", or any appropriate explanatory text. tag The esmtp-value supplied with the TAG esmtp-keyword of the RCPT command for this recipient, if present. 7.4 Returned message body part Unless the sender of the original message requested that the original message not be included in a delivery report, the third body part of a message/delivery-status-notification content should be the returned message, or some portion (e.g. the headers) thereof. The content-id of the returned message body part should be identical to that provided in the returned-content parameter of the message/delivery-report body part for this delivery notification. 8. Conformance requirements K. Moore Expires 16 March 1994 [Page 6] Delivery Reports 16 September 1993 An SMTP server which claims compliance with this specification MUST implement the EHLO command as described in [4], and return the DRPT keyword in response to the EHLO command. In addition, it MUST accept the DRPT, NORET, and TAG parameters of the RCPT command and the MSGID parameter of the MAIL command. When an SMTP server accepts responsibility for delivery of a message to a recipient whose RCPT command contains a DRPT or NORET keyword (by returning a 2xx reply code in response to that command), it also agrees, for each recipient, to either: (a) transfer responsibility for the generation of a delivery notification for that recipient, to another ESMTP server that implements this extension, or (b) transfer responsibility for the generation of such a notification to a gateway into a "foreign" (non-SMTP-based) electronic mail environment, which provides a similar delivery notification facility, arranges for such notifications to be returned to the sender of the message, via a gateway that will translate the foreign delivery notifications into the format defined in [5]. (c) successfuly deliver the message to the mailbox named by the original sender of the message, or (d) generate a delivery status notification in accordance with this specification. 8.1 Transfer of delivery-report information via SMTP If an SMTP client relays a message to an SMTP server which advertises the DRPT keyword in response to the client's EHLO command, the client must issue a MSGID parameter to the MAIL command (if a MSGID parameter was supplied by client's predecessor), and likewise copy the DRPT, RET, and TAG esmtp-keywords and values along with each RCPT command relayed to the server. The server accepts responsibility for generating any requested delivery reports for each recipient for which it returns a positive (2xx) reply code in response to the RCPT command. For any failed recipients, the client must generate a delivery report with an "action" value of "failed", and an "mta" value equal to Internet domain name of the server SMTP. If an SMTP client relays a message to an SMTP server which does not advertise the DRPT keyword in response to the EHLO command, the client must generate a delivery report for each recipient for whom a delivery report is required. For any failed recipients, the client will generate a delivery report with an "action" value of "failed". For any other recipients, the client will generate a delivery report with an "action" value of "relayed". In either case, the "mta" value is set to the Internet domain name of the server SMTP. If DRPT=NEVER for any recipients, the client SMTP should relay the message to those K. Moore Expires 16 March 1994 [Page 7] Delivery Reports 16 September 1993 recipients, (using a separate SMTP session if necessary), with an empty sender address in the MAIL command. 8.2 Gatewaying into a foreign environment If an SMTP server gateways the message into a foreign electronic mail system which supports similar delivery notifications, and can arrange for all notifications issued from within that mail system to be returned via a suitable gateway such that the foreign delivery notifications will be translated into the format defined in [5], then it need issue delivery reports only for those recipients for which the foreign mail system would not agree to deliver the message. The foreign mail system need not support exactly the same semantics for delivery notification that are described here. In particular, the foreign mail system may not be able to honor the sender's request that the message be or not be returned along with a delivery report; and the foreign mail system need not issue reports when mail is forwarded within that environment. (In the latter case the gateway should use the "rcpt" field when translating a delivery report from that environment, rather than the "orig-rcpt" field.) If appropriate delivery notifications from the foreign environment cannot be provided, the SMTP server must issue a delivery report for each recipient, containing an "action" value of "relayed", and an "mta" value equal to the Internet domain of the SMTP server. 8.3 Delivery, forwarding, list expansion Upon final delivery to the recipient's mailbox, as named by the sender), an SMTP must issue any requested delivery reports with an "action" value of "delivered" and an "mta" value equal to the Internet domain of the SMTP server. (Note that this is not necessarily the same as the domain part of the recipient address). If the delivery fails, the "action" value should instead be "failed. When a message is "forwarded" to another recipient address than that specified by the sender, the SMTP which performs the forwarding must issue a delivery report for that recipient (unless DRPT=NEVER), with an "action" value of "forwarded" and an "mta" value equal to the Internet domain of the server performing the forwarding. *** NOTE IN DRAFT: we should use the TAG facility here to allow propagation of delivery reports across mail forwarding boundaries. It would be a shame to allow delivery reports to cross inter-MTS boundaries and not to cross mail forwarding boundaries within RFC 822! *** Successful delivery of a message to an address associated with a mail distribution list cases a delivery report to be generated with an K. Moore Expires 16 March 1994 [Page 8] Delivery Reports 16 September 1993 "action" value of "delivered". Delivery report requests are NOT to be propagated to the members of the distribution list. 9. References [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982. [2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. [3] Westine, A., Postel, J. "Problems with the Maintenance of Large Mailing Lists.", RFC 1211, USC/Information Sciences Institute, March 1991. [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker., D. "SMTP Service Extensions", RFC 1425, United Nations University, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993. [5] Moore, K. "MIME Content-Types For Delivery Status Notifications", Internet-Draft "draft-moore-mime-delivery-00.txt", 16 September 1993. [6] Crocker, D. "Structured Text Information Format (STIF)", Internet- Draft "draft-crocker-stif-00.txt", June 1993. 10. Author's address Keith Moore University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 USA email: moore@cs.utk.edu K. Moore Expires 16 March 1994 [Page 9]